ITEM CAPTURE RESEARCH SYSTEM 

FIELD OF THE INVENTION 

The present invention generally relates to an item capture research system, and 
more specifically, to a method of item capture whereby information is collected on 
5 financial items, e.g., checks, as they progress through the various phases of capture, 

posting, and backend reporting while allowing storage within a single system that may be 
accessed by users at all locations within the organization. 

BACKGROUND OF THE INVENTION 

Systems for archiving transaction data and image data generated by check 
10 processing operations performed by financial institutions are well known. By transaction 
data, we mean not only the information encoded on the check itself, magnetically or 
otherwise, but also the information about the capture process and the handling of the item 
subsequent to the capture process. Image data, of course, refers to an image of the check 
itself, or other financial document of which an image is captured. 
15 Typically, such archive systems are based on relational database management 

systems such as DBE, Oracle or Informix. Large and even medium size financial 
institutions can process hundreds of thousands, if not milhons, of checks (or items) in a 
single day. The information captured must be stored for several years so that information 
relating to an item can be retrieved in connection with various banking operations, such 
20 as retail customer service or treasury or cash management services for commercial 

customers. The costs associated with storing such a large volume of information are very 
high. Thus, there is a need for a system that provides cost effective, long-term storage of 
transaction data and image data generated in connection with the item capture process. 
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As discussed above, financial institutions generate vast amounts of transaction 
data and image data in connection with check or item processing. Item research as it 
relates to retrieving such transaction and image data for use by retail or commercial 
customers of the financial institution, as well as operational personnel, usually to 
5 determine the occurrence or non-occurrence of certain events, such as presentment, 
payment or clearance of an item. 

Item research that is executed at multiple financial institution locations and 
performed across multiple systems is time and resource intensive. Items are typically 
captured on at least two different capture platforms (e.g.. Check Processing Control 

10 System and ImageMark) and capture sites are typically dispersed geographically. As a 
result, substantial human resources are required to research items because multiple 
systems need to be accessed. In addition, the amount of time to research an item and 
dehver a hardcopy (e.g., microfilm-based copy) of the item can take hours and even days. 
Moreover, historical information on these disparate systems is limited. This drain on 

1 5 resources ultimately results in poor customer service. 

Previously available commercial systems, e.g., the Vector 1 1 System available 
from Sterling Commerce of Columbus, Ohio, receive all items from the Check 
Processing Control System ("CPCS") and sort them by a sequence number. There are no 
interfaces to direct deposit account ("DDA") or cash letter systems. Items cannot be 

20 extracted by entry, block or batch. Entry, block and batch svimmarization is also not 
supported. The Vector 1 1 System uses a Customer Information Control System 
("CICS") interface, but does not support a callable interface that can be accessed through 
a variety of host and PC application development languages. Thus, there is a need for an 
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archive system that provides an integrated, efficient and quick item research system. 

SUMMARY OF THE INVENTION 

A system and method for item capture research, comprises an item capture 
subsystem, an image archive subsystem system, a transaction data archive system having 
5 a multiple data structures, and a research engine. 

The image capture subsystem includes a document processor, an image camera 
and an associator. 

The image archive subsystem is comprised of on-us items image database and a 
transit items image database. The on-us items image database stores information about 

1 0 items drawn on a financial institution that is processing the item. It includes the 

following information about on-us items: the bank ID number, account number and 
image date. The transit items image database stores information about stores information 
about items drawn on a financial institution other than the one that is processing the item. 
It includes the following information about on-us items: the sorter ID number, the image 

1 5 date, and the sequence number. The image data archive subsystem also includes a white 
paper image database, which stores information about items other than checks, e.g., 
deposit shps, and includes information about the account number and the image date. 

The image archive subsystem also includes an image data index, which is an 
index to the image data stored in the image databases, and stores information about the 

20 image date, a sorter ID number, a sorter cycle, a sequence number and a database 
identifier. 

The multiple data structures of the transaction data archive subsystem include (i) 
an on-us items data structure, (ii) an all items data structure, and (iii) a cash letter items 



36810 



3 



data structure. 

The on-us items data structure includes an on-us items file, an on-us items archive 
file and an on-us items archive file index. The on-us items file includes MICR codeline 
data, a posted amount, a bank ID number, an account number and a posting date. The 
MICR codeline data includes a routing/transit number, an account number, a serial 
number, a process control field, a sequence number, a payee account number, a 
transaction code and an import source. The on-us items file is a VSAM file and is stored 
onhne on DASD. 

The on-us items archive file includes the same information as in the on-us items 
file, although the on-us items archive file is stored offline on magnetic tape. 

The on-us items archive file index is an index to the on-us items archive file. The 
on-us items archive index is a VSAM file, which is stored online of DASD. 

The all items data structure includes an all entries file, an all items file, and all 
items archive file and an all items archive file index. 

The all entries file includes information about the capture site, capture date, and 
entry number for an item. The entry number consists of block information, which, in 
turn, consists of a block sequence number and a block amount. The block information 
includes batch information, which, in turn, includes a batch sequence number and a batch 
amount. The all entries file is a VSAM file and is stored onhne on DASD. 

The all items file includes item information, such as MICR codeline data, an item 
amount, and an item sequence number. The all items file is a VSAM file, which is stored 
online on DASD. 

The all items archive file has the same structure as the all items file, and is a 
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VS AM file that is stored offline on magnetic tape. 

The all items archive index is an index to the all items archive file and is a VS AM 
file that is stored online on DASD. 

The cash letter items data structure includes a cash letter file, a bundle items file, 
5 a bundle items archive file and a bundle items archive file index. 

The cash letter file includes information about an end point identifier, a cash letter 
date, a cash letter amount and a cash letter time. The cash letter file is a VSAM file that 
is stored online on DASD. 

The bundle items file includes information about a bundle amount, a bundle time, 
10 and a bundle date. A bundle includes at least one item, which is comprised of MICR 
codeHne data and an item amount. The bundle items file is a VSAM file that is stored 
online on DASD. 

The bundle items archive file has the same data structure as the bundle items file. 

It is a VSAM file that is stored offline on magnetic tape. 
15 The bundle items archive file index is an index to the bundle items archive file. 

The bundle items archive index is a VSAM file, stored online on DASD. 

The research engine receives an item request and directs a response to the item 

request, and includes a request interpreter, a request director and a request processor. 

The request interpreter is an all items request interpreter, which is used to search the all 
20 items data structure, or a cash letter request interpreter, which is used to search the cash 

letter items data structure. The request director directs a search request to the request 

processor, such as an all entries request processor, an all items request processor, a cash 

letter request processor or a cash letter items request processor. 
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These and other aspects of the present invention will become apparent to those 
skilled in the art after a reading of the following description of the preferred 
embodiments. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 is a diagram of the item capture research system of the present invention; 
Figure 2 is a diagram of the item capture subsystem of the present invention; 
Figure 3 is a diagram of the transaction data archive subsystem of the present 
invention; 

Figure 4 is an illustration of the record format for the on-us items master file and 
the on-us items archive file; 

Figure 5 is an illustration of the record format of the on-us items archive file 

index; 

Figure 6 is an illustration of the record format of the all entries master file and the 
all entries archive file; 

Figure 7 is a sample all entries master file; 

Figure 8 is an illustration of the format of the all items master file and the all 
items archive file; 

Figure 9 is a sample all items master file; 

Figure 10 is an illustration of the format of the cash letter master file and the cash 
letter archive file; 

Figure 1 1 is a sample cash letter master file; 

Figure 12 is an illustration of the format of the bundle item master file and the 
bundle item archive file; 
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Figure 13 is a sample bundle item master file; 

Figure 14 is a diagram of the image data archive subsystem of the present 
invention; 

Figure 15 is an illustration of the record format of the on-us image database; 

Figure 16 is an illustration of the record format of the transit image database; 

Figure 17 is an illustration of the record format of the white paper image database; 

Figure 18 is a diagram of the research engine of the item capture research system 
of the present invention; 

Figure 19 is an illustration of the Entry and Item Retrieval Screen of the present 
invention; 

Figure 20 is an illustration of the Entry Listing Screen of the present invention; 
Figure 21 is an illustration of the Block/Batch Listing Screen of the present 
invention; 

Figure 22 is an illustration of the Block/Batch Detail Screen of the present 
invention; 

Figure 23 is an illustration of the On-Us Item Detail Screen of the present 
invention; 

Figure 24 is an illustration of the Transit Item Detail Screen of the present 
invention; 

Figure 25 is an illustration of the Transit Item Cash Letter Detail Screen of the 
present invention; 

Figure 26 is an illustration of the Transit hem Cash Letter Detail Screen of the 
present invention; 
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Figure 27 is an illustration of the Specific Item Search Listing Screen of the 
present invention; 

Figure 28 is an illustration of the Specific Item Search Listing Screen with CCIF 
data of the present invention; 

Figure 29 is an illustration of the Cash Letter Retrieval Screen of the present 
invention; 

Figure 30 is an illustration of the Cash Letter Listing Screen of the present 
invention; 

Figure 31 is an illustration of the Cash Letter Bundle Listing Screen of the present 
invention; 

Figure 32 is an illustration of the Bundle Listing Screen of the present invention; 
Figure 33 is an illustration of the Cash Letter Bundle Detail Screen of the present 
invention; 

Figure 34 is an illustration of the Cash Letter Item Detail Screen of the present 
invention; and 

Figure 35 is an illustration of the Cash Letter All Item Detail Screen of the present 
invention; 

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 

Figure 1 is a diagram illustrating the main components of the system of the 
present invention. The system 10 integrates the capture, posting and research processes 
into a single system that quickly delivers item information and the associated image of 
the corresponding item or document from anywhere in a business organization, e.g., a 
financial institution, regardless of the user's physical location. 
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• System 10 Overview 

As shown in Figure 1, the system 10 includes an item capture subsystem 12, a 
transaction data archive subsystem 14 and an image data archive subsystem 16. Items, 
such as checks, white paper, and proof of deposit documents are received by the item 

5 capture subsystem 12. Transaction data relating to the item is extracted and stored in the 
transaction data archive subsystem 14. Likewise, image data, including an image of the 
item, is extracted and stored in the image data archive subsystem 16. The system 10 also 
includes a research engine 18, which receives and responds to requests for transaction 
and image data stored in the transaction data archive 14 and the image data archive 16. 

10 Both the transaction data archive 14 and the image data archive 16 use matrix 

structures for indexing data. Such a structure is advantageous in managing the large 
amounts that are captured and stored in high volume check processing operations. Such a 
structure does not require the use of an additional database management system (either 
relational or hierarchical) to support the database structures, thus requiring less 

15 processing resources and attendant support personnel. Also, such a structure can 

accommodate high volume import and data loading associated with high volume check 
processing. In addition, maintenance and/or reorganization of the data files can be 
achieved with minimal impact on archive availability. Such a structure allows for data 
loading and backup without negatively affecting image or data retrievals. Finally, the 

20 structure is flexible and therefore easily modifiable. 
• Item Capture Subsystem 12 

Figure 2 shows the item capture subsystem 12 in more detail. An exemplary item 
capture subsystem 12 is the Check Processing Control System ("CPCS") available from 
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International Business Machines ("IBM") of Armonk, New York. The item capture 
subsystem 12 extracts CPCS strings from the captured item, including, input strings (I- 
strings), merged strings (M-strings), 99M strings, input creation files (ICRE) and master 
creation files (MCRE). 

5 An I-string is a string of data that is captured during the prime pass entry. An M- 

string represents the merging of data and images from the prime pass I-string with 
corrected reject data. Reports that result from the M-string allow for reconciliation and 
balance input, which ensures that all items are captured. Once the reject repair process is 
completed, the M-string becomes a 99M-string, which is a fully balanced string of items. 

10 An ICRE is a concatenation of all the 99M-strings for a period of time for a particular 

capture site, depending the organization's balancing procedures. A MCRE is a subset of 
the ICRE, and it represents all transit items. 

Images also can be imported using, for example, the ImageMark Proof of Deposit 
system, which is available from NCR Corporation of Dayton, Ohio. 

1 5 Check images also can be imported from the BancTec Retail Lockbox System, 

which is available from BancTec, Inc. of Irving, Texas. 

White paper images and check fransactional data also can be imported from the 
RemitVision Lockbox capture system, available from Alysis Technologies of Emeryville, 
California. 

20 Referring to Figure 2, preferably, the item capture subsystem 12 includes a 

document processor 20, an image camera 22 and an associator 24. While the document 
processor 20 and the image camera 22 are shown as separate components for purposes of 
illustration, these two components may be combined into the same hardware/software 
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platform. 

• Document Processor 20 

An exemplary document processor 20 is an IBM 3890/XP Series document 
processor, also available from IBM. Such a document processor is a high-speed, high- 

5 volume document processor that reads magnetically-inscribed documents or optical- 
character documents. As items are captured, the document processor 20 creates an I- 
string, which includes every document read by the document processor, including control 
documents and rejected documents. Each record contains related information, such as the 
pocket selected. The I-string also includes internally-generated control records. 

10 • Image Camera 22 

An exemplary image camera 22 is available with the IBM 3890/XP Series 
document processor, which is available from IBM. hnages captured by the item capture 
subsystem 12 are sent to the archive subsystem 16, where they are stored and managed. 

• Associator 24 

15 The associator 24 receives transaction data for an item from the document 

processor 20 and image data for the same item from the image camera 22 and associates 
the item's transaction data with the corresponding image and image data for that item. 
• Transaction Data Archive Subsystem 14 

Figure 3 shows the transaction data archive 14 in more detail. The transaction 

20 data archive is comprised of three separate, integrated data structures, namely, an on-us 

items data structure 30, an all items data structure 32 and a cash letter items data structure 
34. Each of these data structures will be discussed in more detail below. 

• On-Us Items Data Structure 30 
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Returning to Figure 3, the on-us items data structure 30 includes an on-us items 
master file 30a, an on-us items archive file index 30b and an on-us items archive file 30c. 
The on-us items data structure 30 contains all data for on-us items, which are checks or 
other financial documents drawn on the financial institution that is processing them. 
5 Each of these components of the on-us items data structure 30 will be discussed in more 
detail below. 

• On-Us Items Master File 30a 
The on-us items master file 30a is comprised of multiple virtual storage access 
method (VSAM), keyed-sequence data set (KSDS) files by commercial account and retail 

1 0 account. A VSAM file is a file management system used on IBM mainfi-ames. VSAM 
speeds up access to data in files by using an inverted index (called a B+tree) of all 
records added to each file. Many legacy software systems use VSAM to implement 
database systems, which are called data sets. A KSDS file is a VSAM file or data set 
whose records are loaded in key sequence and controlled by an index. 

15 As illustrated in Figure 4, a record in the on-us items master file 30a includes the 

following fields: Bank ID Number 41, Account Number 42, Sequence Number 43, Serial 
Number 44, Amount 45, Routing/Transit Number 46, Process Control Field 47, Payee 
Account Number 48, Transaction Code 49, Credit Account Code 50, Import Source 51 
and Posting Date 52. The primary key for the on-us items master file 30a is comprised of 

20 the Bank ID Number 41, Payor Account Number 42 and Sequence Number 43. The 

alternate key is comprised of Serial Number 44 and Amount 45. The Bank ID Number 
41, the Account Number 42 the Serial Number 44 and the Process Control Field 47 are 
data elements of the MICR codeline. 
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• On-Us Items Archive File Index 30b 

As illustrated in Figure 5, a record in the on-us items archive index file 30b 
includes the following fields: Bank ID Number 55, Payor Account Number 56 and 
Posting Date 57. The key for the On-Us Items Archive File Index 30b are the same three 
fields, which are for retrieval of item information based on the user's knowledge of the 
customer account number. Such a structure obviates the need to search the all items 
archive file, which is a considerably larger file, thereby saving time and money in item 
research. 

• On-Us Items Archive File 30c 

The fields in a record in the on-us items archive file 30c are the same as those for 
a record in the on-us items master file 30a. 
• All Items Data Structure 32 

Returning to Figure 3, the all items data structure 32 is comprised of an all entries 
master file (AEMF) 32a, an all items master file (AIMF) 32b, and an all items archive file 
(AIAF) 32c. 

• All Entries Master File 32a 

The AEMF 32a is comprised of multiple virtual access storage method VSAM, 
KSDS files by CPCS entity, i.e., capture site, and month. 

Figure 6 shows the fields in a record (AEMF-RECORD) in the AEMF 32a. As 
shown in Figure 6, the key for the AEMF 32a is comprised of the CPCS entity, i.e., 
capture site (AEMF-KEY-APPL-SITE), capture date (AEMF-KEY-APPL-DATE), 
capture sorter (AEMF-KEY-CAPT-SORT), entry number (AEMF-KEY-CAPT-ENTRY- 
NUMB), and record number (AEMF-KEY-CAPT-REC-NUMB). The record includes all 
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of the block and batch data for an entry. Entries with more than 32K of data will use 
more than one AEMF record. The records contain the string data from the ICRE string 
header records and the capture sequence number range for the entry. It should be noted 
that the AEMF-BLOCK-DATA field will occur from 0 to 20 times depending on the 
5 value in the AEMF-ENTRY-NUMB-BLOCKS field. 

Figure 7 is a sample all entries master file. 

• All Items Master File 32b 
The AIMF 32b is comprised of multiple VSAM, KSDS files by CPCS entity, i.e., 
capture site, and month. The AIMF 32b is contains data about all items captured by the 
10 item capture subsystem, both on-us items and transit items. The AIMF 32b, which 
archives all items in the order they were processed, facilitates deposit research and 
rebuilds of customer account statements. 

Figure 8 shows the fields in a record (AIMF-RECORD) in the AIMF 32b. As 
shown in Figure 8, the key to the AIMF 32b is comprised of the CPCS entity (AIMF- 
1 5 KEY-APPL-SITE), capture date (AIMF-KEY-APPL-DATE), entry number (AEMF- 
KEY-ENTRY), batch sequence number (AIMF-KEY-LAST-SEQU), record number 
(AIMF-KEY-RECD-NUMB) and record type (AIMF-KEY-RECD-TYPE). The last 
sequence number on the record is set to the last sequence number relative to the sorter the 
batch was captured on. There is one logical AIMF record for each batch in the ICRE file. 
20 There are multiple AIMF records for batches that have more than 250 items. The records 
contain the batch key and one or more segments for each item in the batch. Each item 
record contains the item data, credit account data, cross reference data for on-us items 
and the cash letter data for fransit items. It should be noted that the AIMF-ITEM field 
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occurs 0 to 350 times, depending on the value in the AMF-BATCH-NUMB-ITEMS 
field. 

Figure 9 is a sample all items master file. 

The AIMF 32b is created from the ICRE, MCRE and cash letter system. 
5 • All Items Archive File 32c 

The AIAF 32c is comprised of multiple NearArchive databases by CPCS entity. 
As is known to those skilled in the art, a NearArchive database is available from Storage 
Technology Corporation of Louisville, Colorado. The AIAF 32c is used to store item 
data after it is migrated from the AIMF 34b. The All Entries Archive File (AEAF) 32c 
10 has the same record structure as the AIMF 32b. 

As is known to those skilled in the art, there is an onhne index (not shown) to 
AIAF 32c. By online index, we mean that the index to the AIAF 32c is stored in a direct 
access storage device (DASD). 

• Cash Letter Data Structure 34 
1 5 Returning to Figure 3, the cash letter structure 34 is comprised of a cash letter 

master file (CLMF) 34a, a bundle item master file (BIMF) 34b, and a bundle item archive 
file (BL^) 34c. 

• Cash Letter Master File 34a 
The CLMF 34a is comprised of multiple VSAM, KSDS files by CPCS entity, i.e., 
20 capture site and month. The CLMF 34a contains information about all transit items 

captured by the item capture subsystem. Transit items are checks drawn on the financial 
institution by institutions other than the financial institution that is processing them. The 
CLMF 34a, which archives transit items in dispatched order, facilitates cash letter and 
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kill bundle research and rebuilds. 

Figure 10 shows the fields in a record (CLMF-RECORD) in the CLMF 34a. As 
shown in Figure 10, the key to the CLMF 34a is comprised of the CPCS entity (CLMF- 
KEY-CL-PROC-SITE), cash letter process date (CLMF-KEY-CL-PROC-DATE), cash 
letter system date (CLMF-KEY-SYST-DATE), end point (CLMF-KEY-CL-END- 
POINT), cash letter time (CLMF-KEY-CL-TIME), cash letter amount (CLMF-KEY-CL- 
AMNT) and ACLS record number (CLMF-KEY-ACLS-NUMB). The record stores all 
cash letter and bundle information. The records are based on the ACLS information. It 
should be noted that the CLMF-CL-BUNDLE-DATA field occurs 0 to 400 times, 
depending on the value in the CLMF-CL-NUMBER-BUNDLES field. 
Figure 1 1 is a sample cash letter master file. 
• Bundle Item Master File 34b 

The BIMF 34b is comprised of multiple VSAM, KSDS files by CPCS entity, i.e., 
capture site, and month. The BIMF 34b is an index to each transit item in each bundle in 
each cash letter. 

Figure 12 shows the fields in a record (BIMF-RECORD) in the BIMF 34b. As 
shown in Figure 12, the key to the BIMF 34b is comprised of the capture site (BIMF- 
VSM-KEY-APPL-SITE), capture date (BIMF-VSM-KEY-APPL-DATE), end point 
(BIMF-VSM-KEY-END-POINT), bundle date (BIMF-VSM-KEY-BUNDLE-DATE), 
bundle time (BIMF-VSM-KEY-BUNDLE-TIME) and bundle amount (BIMF-VSM- 
KEY-BUNDLE-AMNT). There is one logical BIMF record for each record in the 
MCRE file. There are muhiple BIMF records for bundles that have more than 550 items. 
The record contains one or more segments for each item in the bundle. 
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Figure 13 is a sample bundle item master file. 
• Bundle Item Archive File 34c 

The BIAF 34c is comprised of multiple NearArchive databases by CPCS entity. 
The BIAF 34c is used to store cash letter data after it migrated from the BIMF 34b. The 
BIAF 34c has the same record structure as the BIMF 34b. 

As is known to those skilled in the art, there is an online index (not shown) to 
BIAF 34c. 

• Transaction Data Archive Storage 

As previously mentioned, preferably, index data is stored on a direct access 
storage device (DASD) for a period of one year. After one year, the index data is written 
to a long term, offline storage media, such as magnetic tape. By offline storage, we mean 
non-DASD storage, such as magnetic tape. Preferably, the index data is organized using 
archive objects. Preferably, the archive objects are created using the NearArchive 
software and object structures, which are available from Storage Technology Corporation 
of Louisville, Colorado. The migration of the fransaction data to magnetic tape is 
performed on a monthly basis so that the transaction data for a month can be restored 
when a retrieval request that spans that date range is performed. 

Preferably, the on-us, all items and cash letter databases can have different storage 
rules and are archived to separate archive objects. A VSAM index file of relatively small 
size is maintained on DASD and points to the correct archive object on magnetic tape. A 
retrieval request specifies the data or data range and the system will resolve the archive 
object that needs to be restored in order to satisfy the retrieval request. 
• Image Data Archive Subsystem 16 
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Returning to Figiire 1, the system 10 further includes an image data archive 
subsystem 16. The image data archive subsystem 16 is shown in greater detail in Figure 
14. 

As shown in Figure 14, the image data archive subsystem 16 is comprised of 
image data file 141 and an image data index 142, which are stored in a DASD. The 
image data archive subsystem 16 is also comprised of an on-us item image database 143, 
a transit item image database 144 and a white paper image database 145. 

• Image Data File 141 

Preferably, the image data file 141 is a CIMS database, which is available from 
Check Solutions of Memphis, Tennessee. The image data file 141 is supported using the 
High Performance Transaction System ("HPTS") software available from IBM of 
Armonk, New York. The image data file 141 is comprised of directory files and data 
files. There are unique directory files by capture sorter and unique data files by capture 
entry. Preferably, on-us and lockbox image data is stored in DASD for 45 calendar days, 
while transit image data is stored in DASD for three calendar days. 

• Image Data Index 142 

The image data index 142 is comprised of the following fields: Image Date, Sorter 
ID Number, Sorter Cycle, Sequence Number and Database Name. 

• On-Us Item Image Database 143 

The on-us image database 143 is composed of multiple NearArchive tape 
databases by bank, commercial/retail apphcation type, and account key range. On-us 
check, deposit and lockbox image data is stored in the on-us item image database 143. 

Figure 15 shows the following fields in a record in the on-us items image database 
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143: Image Date 151, Bank ID Number 152, Account Number, 153, Sequence Number 
154, Sorter ID Number 155, Sorter Cycle 156 and Image Data 157. An image key is 
comprised of the following fields: Image Date 151, Sorter ID Number 155, Sorter Cycle 
156 and Sequence Number 154. 
5 • Transit Item Image Database 144 

The transit item image database 144 is comprised of multiple NearArchive tape 
databases by capture sorter. Transit item image data is stored in the transit item image 
database 144. 

Figure 16 shows the following fields in a record in the transit item image database 
10 144: Image Date 161, Sequence Number 162, Sorter ID Number 163, Sorter Cycle 164 
and Image Data 165. An image key is comprised of the following fields: Image Date 
161, Sorter ID Number 163, Sorter Cycle 164 and Sequence Number 162. 
• White Paper Image Database 145 

The white paper image database 145 is comprised of multiple NearArchive tape 
15 databases. 

Figure 17 shows the fields for a record in the white paper image database 145: 
Image Date 171, Bank ID Number 172, Account Number. 173, Sequence Number 174, 
Sorter ID Number 175, Sorter Cycle 176 and Image Data 177. An image key is 
comprised of the following fields: hnage Date 171, Sorter ID Number 175, Sorter Cycle 
20 1 76 and Sequence Number 1 74 . 

The Image Date is the date the image was captured. The Bank ID Number is the 
identification number of the bank or other financial institution association with the 
Account Number. The Account Number is the account number for the customer 
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associated with the image. Sequence Number is the sequential number assigned to the 
item as it was captured by the sorter. Sorter ID Nimiber is the number used to identify 
the sorter upon which the image was captured. Sorter Cycle is the cycle of the sorter 
upon which the image was captured, hnage Data is the image in a digitized format of the 
5 item captured. 

• hnage Storage 

hnage data is stored on DASD on a short term basis, which provides quick 
response. Preferably, the HPTS and CMS database is used for DASD storage. The 
parameters for short term storage are stored in a control file, which specifies where 

10 images are stored and for how long. As discussed above, images can be classified as 

either on-us images or transit images, each of which has its own retention period. A third 
classification of images, white paper images, also can have its own retention period. 

Images are stored on a long term basis on StorageTek 9840 drive and tapes 
coupled with the StorageTek Automated Cartridge Systems, all of which are available 

1 5 fi-om Storage Technology Corporation of Louisville, Colorado. 
• Research Engine 18 

Returning to Figure 1, the system 10 further includes a research engine 18. The 
item capture research system 10 provides a variety of search options and provides access 
to the system through a variety of user interfaces, such as an IBM 3270 terminal or a 

20 graphical user interface of a personal computer. Preferably, transaction and image is 
available for up to seven years. 
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Figure 18 is a diagram of the components of the research engine 18. The research 
engine 1 8 supports two separate interfaces, an all items research interface and a cash 
letter items research interface. 

To initiate a search of all items, the all items request interpreter 180 is initiated by 
5 the user. Similarly, to initiate a search of cash letter items, the cash letter request 
interpreter 181 is initiated by the user. 

Once an interpreter is initiated, the user sends a research request to the request 
director 182 via either of the interpreters, 180 or 181. The request director 182 directs the 
research request to one of four request processors, which are discussed in more detail 
10 below. 

If the research request is for entry, block or batch information, the request director 
182 directs the research request to the all entries request processor 183. The all entries 
request processor 183 retrieves the requested information from the all entries master file 
(not shown), accumulates the requested entry, block or batch information and returns it to 
1 5 the all items request interpreter 1 80 via the request director 1 82. 

If the research request is for a particular item, the request director 182 directs the 
research request to the all items request processor 184. The all items request processor 
184 retrieves the requested item information from either the all items master file or the all 
items archive file (not shown), accumulates the requested item information and returns it 
20 to the all items request interpreter 1 80 via the request director 1 82. 

If the research request is for cash letter information, the request director 182 
directs the research request to the cash letter processor 185. The cash letter processor 185 
retrieves the requested information from the cash letter master file (not shown), 
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accumulates the requested cash letter information and returns it to the cash letter request 
interpreter 181 via the request director 182. 

If the research request is for a particular bundle or cash letter item, the request 
director 1 82 directs the research request to the cash letter items processor 1 86. The cash 
5 letter items request processor 1 86 retrieves the requested information from either the 
bundle items master file or the bundle items archive file (not shown), accumulates the 
requested bundle or cash letter item information and returns it to the cash letter request 
interpreter 181 via the request director 182. 

The retrieval logging processor 1 87 logs all of the transactions performed by the 
10 request processors, 183, 184, 185, 186. For example, the retrieval logging processor 
records user, start time of request, end time of request, processing time, number of 
records processed and number of records returned. Such information could be used for 
system administration or customer billing. 

The end point information processor 188 provides detailed information about a 
1 5 cash letter from the end point master file (not shown), such as name, address, contact 
person and telephone number for the bank receiving a cash letter. 

The image data archive 1 89 provides on-us transaction history information to the 
all items request interpreter 180. 

The customer control information file 190 provides customer name and address 
20 information to either of the request interpreters 180 or 181 via the request director 182. 
• Maintenance Processing Module 

The system collects information on items as they progress through the various 
phases of capture, posting and backend reporting. The information is stored within a 
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single system that provides a variety of search options to users at all locations throughout 
the organization, which allows for quick retrieval (i.e., within seconds or minutes) of item 
data and the associated image. 
• Retrieval Processing Module 

5 The system 10 also includes a retrieval processing module, which allows for 

search and retrieval of item and image information via traditional CICS screens and 
graphical user interfaces. 

The following entry and item CICS screens are provided for: 

Figure 19 is the Entry and Item Retrieval Screen 191 . The Entry and Item 

10 Retrieval Screen 191 is used to initiate entry and item searches. The Capture Site 191A 
and Capture Date 191B range fields are required. The Post Date 191C range and Capture 
Date 19 IB range must be set to equal values if any of the item criteria is specified. The 
Entry 191D range, Sequence Number 191E, and Item Amount 191F fields are optional. 
The Entry Listing Screen 200 (Figure 20) is returned if the search criteria yield multiple 

1 5 entries. The Specific Item Search Listing Screen 270 (Figure 270) is returned if the Item 
Amount 191F criterion is specified and more than one item meets the search criteria. The 
On-Us Item Detail Screen 230 (Figure 23) or the Transit Item Detail Screen 250 (Figure 
25) is returned if the Sequence Number 191E criteria is specified and a single item 
satisfies the search criteria. 

20 Figure 20 is the Entry Listing Screen 200. The Entry Listing Screen 200 can be 

used to either scroll through a list of entries or to selected additional information for a 
specific entry. The Block/Batch Listing Screen 210 (Figure 21) is presented once the 
additional information for a specific entry is requested. 
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Figure 21 is the Block/Batch Listing Screen 210. The Block/Batch Listing Screen 
210 is used to either scroll through a list of batches or to selected additional information 
for a specific batch. The Block/Batch Detail Screen 220 is presented once the additional 
information for a specific batch is requested. 
5 Figure 22 is the Block/Batch Detail Screen 220. The Block/Batch Detail Screen 

220 is used to either scroll through batch detail items or to select additional information 
for a specific item. The On-Us Item Detail Screen 230 or the Transit Item Detail Screen 
250 is presented once the additional information for a specific item is requested. 

Figure 23 is the On-Us Item Detail Screen 230. The On-Us Item Detail Screen 
1 0 230 is used to present detail information for a specific on-us item. 

Figure 24 is the On-Us Archive Item Detail Screen 240. The On-Us Archive Item 
Detail Screen 240 is used to present detail information for a specific on-us item. 

Figure 25 is the Transit Item Detail Screen 250. The Transit Item Detail Screen 
250 is used to present additional information for a specific transit item. 
1 5 Figure 26 is the Transit Item Cash Letter Detail Screen 260. The Transit Item 

Cash Letter Detail Screen 260 is used to present additional information for a specific 
transit item. 

Figure 27 is the Specific Item Search Listing Screen 270. The Specific Item 
Search Listing Screen 270 is used to scroll though the items meeting the search criteria or 
20 to select additional information on a specific item. The On-Us Item Detail Screen 230 or 
the Transit Item Detail Screen 250 is presented once additional information for a specific 
item is requested. 

Figure 28 is the Specific Item Search Listing Screen 280 with CCIF data. The 
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Specific Item Search Listing Screen 280 is used to scroll through the items meeting the 
search criteria or to select additional information on a specific item. The On-Us Item 
Detail Screen 230 or the Transit Item Detail Screen 250 is presented once additional 
information for a specific item is requested. 

The following cash letter CICS screens are provided for: 

Figure 29 is the Cash Letter Retrieval Screen 290. The Cash Letter Retrieval 
Screen 290 is used to initiate a cash letter search. The Capture Site 290A and Cash Letter 
Date 290B range fields are required. The Cash Letter Bundle Amount 290C range. End 
Point 290D, and Item Amount 290E range fields are optional. The Cash Letter Listing 
Screen 300 is returned if the Item Amount 290E search criteria is specified and a single 
item matches the search criteria. 

Figure 30 is the Cash Letter Listing Screen 300. The Cash Letter Listing Screen 
300 is used either to scroll through a list of cash letters or to select additional information 
for a specific cash letter. The Cash Letter Bundle Listing Screen 310 (Figure 31) is 
presented once the additional information for a specific cash letter is requested. 

Figure 3 1 is the Cash Letter Bundle Listing Screen 310. The Cash Letter Bundle 
Listing Screen 310 is used to scroll through a list of bundles or to select additional 
information for a specific bundle. The Cash Letter Bundle Detail Screen 330 is presented 
once the additional information for a specific bundle is requested. 

Figure 32 is the Bundle Listing Screen 320. The Bundle Listing Screen 320 is 
used to scroll through a Hst of bundles or to select additional information for a specific 
bundle. The Bundle Listing Screen 320 is presented for a bundle request by end point or 
bundle amount range. The Cash Letter Bundle Detail Screen 330 (Figure 33) is presented 
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once the additional information for a specific bundle is requested. 

Figure 33 is the Cash Letter Bundle Detail Screen 330. The Cash Letter Bundle 
Detail Screen 330 is used to scroll through bimdle detail or to select additional 
information for a specific item within a bundle. The Cash Letter Bundle Detail Screen 
5 330 is presented once the information for a specific bundle item is requested. An Item 
Amount 330A search is initiated by entering the Item Amount criteria. 

Figure 34 is the Cash Letter Item Detail Screen 340. The Cash Letter Item Detail 
Screen 340 is used to present additional information for a specific cash letter item. 

Figure 35 is the Cash Letter All Item Detail Screen 350. The Cash Letter All Item 
10 Detail Screen 350 is used to present additional information for a specific cash letter item. 

The description of the preferred embodiments contained herein details the many 
ways the present invention can provide its intended purposes. While several preferred 
embodiments are described, it is apparent that various changes might be made without 
departing from the scope of the invention. 
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